   <!DOCTYPE html>
<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="viewport" content="width=device-width, user-scalable=no" />
<title>Tiny Java Web Server aka Miniature JWS</title>
<style>
<!--
.quotes      { font-family: Arial; font-size: 8pt }
.msg{}
td{}
.au{font-weight:bold}
#mm, .tdc{font-family:arial,sans-serif;font-size:80%;white-space:nowrap;background-color:#C0C0C0}
    .style1
    {
        text-decoration: underline;
    }
td#cmd {border-style: none none solid none; border-width: 1px; border-color: #0aa;}
    .style2
    {
        width: 124px;
    }
    .style3
    {
        width: 124px;
        height: 42px;
    }
    .style4
    {
        height: 42px;
    }
    .style5
    {
        width: 124px;
        height: 24px;
    }
    .style6
    {
        height: 24px;
    }
-->
</style>
</head>

<body bgcolor="#D1E9FE">

<h2 align="center">Tiny Java Web Server and Servlet Container</h2>

<p align="center">aka Miniature JWS</p>
<p align="right">European quality software made in USA</p>
<p align="center"><i>(with Android <strong>SSL</strong> support)</i></p>
<p align="right"><i>Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.</i></p>
<table border=0 width="100%"><tr><td align=left width="80%"><b><i><a href="#download">Download</a></i></b></td>
<td align=right><a href="https://github.com/drogatkin/TJWS2/releases/tag/v1.117"><img src="http://today.java.net/images/javanet_button_90.gif" border=0></a><a href="https://github.com/drogatkin/7Bee" target="_blank">7Bee</a></td></tr>
<tr>
<td>
  <ol>
  <li><a href="#introduction">Introduction</a></li>
        <li><a href="#features">Features</a> </li>
        <li><a href="#history">History</a> </li>
        <li><a href="#competitors">Competitors</a> </li>
        <li><a href="#design">Design</a> </li>
        <li><a href="#configuration">Configuration</a>
         <ul type=disc><li title="Setup SSL">6.1 <a href="#command">Command line parameters</a></li>
             <li title="Setup SSL">6.2 <a href="#service">Run as service</a></li>
             <li>6.3 <a href="#security">Security</a></li>
         </ul> 
        </li>
        <li><a href="#j2ee">J2EE deployment</a> </li>
        <li><a href="#appservices">App server services (JNDI, DataSource)</a></li>
        <li><a href="#embedded">Embedded usage</a> </li>
        <li><a href="#embedable">Embeddable application</a> </li>
        <li><a href="#mobile">Mobile and appliance usage</a> </li>
        <li><a href="#service">As a service</a> </li>
        <li><a href="#virtual">Virtual hosting configuration</a></li>
        <li><a href="#proxy">Proxied usage</a></li>
        <li><a href="#download">Download</a> </li>
        <li><a href="#build">Build</a></li>
        <li><a href="#apps">Applications</a> </li>
        <li><a href="#vm">VM</a> </li>
        <li><a href="#support">Support</a> </li>
        <li><a href="#version">Versions</a> </li>
        <li><a href="#copyright">Copyright</a> </li>
        <li><a href="#contact">Contact</a> </li>
    </ol>
  </td>
  <td>
    Construction zone
  </td>
  </tr>
  </table>
    <a name="introduction"></a><h4>
        Introduction</h4>
    <p>
        The Miniature Java Web Server is built as a servlet container with HTTPD servlet providing
        standard Web server functionality. The server is a small as in Java code
as in a result byte code. General purpose of the Web server is running and
debugging servlets. However, it can be used as a regular web server for sites 
with low to medium load. I found also
very convenient shipping a servlet based product packaging with the server, so a user
can start a product just after unwrapping. You can try a <a href="http://knitknot.info/" target="_blank">web
site</a> hosted on this server on a private Cloud. This web server also works on PDA and smart phones as Android and Blackberry based, or on Windows CE based when JVM installed.
 It gives additional flexibility for your phone, since using WebFolder (<a href="http://www.slideshare.net/slideshow/embed_code/12142606" target="_blank">WebBee</a> web app)
 
 can simplify file synchronization and provide control of your phone from web.</p>
<table border="0" width="100%" id="table1" cellpadding="3">
	<tr>
		<td width="148" bgcolor="#99CCFF" valign="top" style="height: 425px">
		<h3>Testimonies</h3>
		<p class="quotes">Using tjws with WebServices as a &quot;RMI&quot;/RPC protocol, and with 
		HTTPS on<br>
		top, this is gold! Thanks! </p>
		<p class="quotes">I've downloaded
		TJWS and it looks like 
		exactly what I&quote;ve been looking for to use as a local web server to 
		generate a web application. 
		<p class="quotes">I'm using the miniature java webserver on<br>
		my zaurus.<br>
		I wrote a few servlets for it and I'm very happy with how it performs.
		<p class="quotes">
		TJWS was the only thing out there I found I could use 
as a library, programmatically within unit tests.  Thanks for a great 
library.
		</td>
		<td style="height: 425px">
<a name="features"></a><h4>Features and Benefits</h4>
<ul>
  <li>About 100Kb footprint (TJWS is the smallest one, like
    5 times less than competitors <a href="http://www.gefionsoftware.com/" target="_blank">LWS</a>
    and <a href="http://jetty.mortbay.org/jetty/index.html" target="_blank">Jetty</a>, 
	more than twice less than <a href="http://winstone.sourceforge.net" target="_blank">Winstone</a>)</li>
  <li>Very fast and reliable, it performs better than some C/C++ based web servers, 10%
      faster than Apache 2.x</li><li>Can scale to thousands connections, clustering configuration is about of
    development</li>
  <li>A perfect solution for web interfaced applications</li>
  <li>Standard J2EE servlet deployment for .war packaged applications</li>
	<li>Simple configuration, no hundreds of config parameters</li>
  <li>Flexible JSP support</li>
    <li>Limited JSS 3.0 support (JSR 315)</li>
    <li>JSR 356 support (websocket). See release <a href="wskt-notes.html">notes</a></li>
    <li>Built for Java 7 with intelligent downgraded support for Java 2
    </li>
    <li>Runs on Android and Blackberry platforms out of the box</li>
</ul>
<a name="history"></a><h4>History</h4>
<p>I was looking for a web server with sources to debug some servlets at the end of 1998. One of my findings

was ACME Java Web Server. It was pretty good, but supported only JSS 1.x and JDK 1.02. Since my servlets required a bit more, I have added
support for contemporary versions of JDK and JSDK. I just continued adding
more features and providing bug fixes after. The current version is mostly
compatible with the latest servlet container specification (3.1) and offers also websocket support.</p>
		</td>
	</tr>
</table>
<a name="competitors"></a><h4>
    Competitors</h4>
<p>
    Main competitors for TJWS are Winstone, LWS, and Jetty. TJWS can successfully compete
    with more established and reputable servers as Tomcat, Glassfish, and JBOSS. Main benefits of TJWS are
    simplicity and tiny footprint.</p>
<a name="design"></a><h4>
    Design
</h4>
    <p>
        Modular design is used for TJWS. It gives a flexibility of creation different configurations
        with exactly required features. A heart of TJWS is a light weight servlet container.
        A set of predefined servlets extends functionality of the container transferring
        it to a web server or/and an application server. Predefined servlets can be eliminated
        or redefined for extra flexibility.</p>
    <p>
        <img src="tjws-block.gif" border=0/></p>
    <p>
        Selecting or not J2EE deployment gives an extra flexibility in a final 
size of a deployed application. Like for an embeddable or a mobile application is possible 
to use Java Personal Profile 1.x compatible servlet container module. For 
less critical in size deployment is possible to use J2EE deployment module and 
JSP module. Originally provided GNU JSP providers have been withdrawn from latest TJWS version for keeping pure
BSD license, however GNU JSP providers can be reached in previous versions. I do not support them anyway.
Only <a href="#jasper">Jasper</a> is currently supported as JSP provider. However I separate it to avoid any licensing issues.
Base module, and J2EE deployment modules have sizes 110K, and 80K
correspondingly. Jasper's size is about 930K. (I am still looking for help to separate Jasper on runtime and JSP parsing and compilation parts,
it could be beneficial for Android deployment.) App server services module adds 46Kb. And finally websocket module adds 65Kb</p>
<a name="configuration"></a><h4>
    Configuration</h4>
    <p>
        Most of server configuration is based on command line arguments. The arguments can
        be processed from a file as well. Additional configuration values can be provided
        over files. J2EE deployed application are configured based on standard web.xml deployment
        descriptor.</p>
    <a name="command"></a><h5>
        Command line parameters</h5>
<p>All command line parameters start with '-' (dash) and most of them have a following value
part. Here they are:</p>
<table border=0>
  <tr><td class="style2"><b>p</b></td>
     <td id="cmd">specifies port number served by TJWS, default value is 80 for non secure
and 443 for secure configuration, for example -p 8080</td>
  </tr>
  <tr id="cmd"><td class="style2"><b>t</b></td>
     <td id="cmd">specifies name of throttles definition file. It allows to reduce
speed accessing to particular files and improve overall performance of a server.
An example of this file can look like:
<table class=tdc>
<tr><td>
<pre><code>
# throttle file for tjws.sourceforge.net
*               100000  # limit total web usage to 2/3 of our T1
*.jpg|*.gif     50000   # limit images to 1/3 of our T1
*.mpg           20000   # and movies to even less
mediachest/*    20000   # MediaChest's pages are too popular</code></pre>
</td></tr>
</table>
</td>
  </tr>
  <tr id="cmd"><td class="style2"><b>s</b></td>
     <td id="cmd">specifies servlet properties file in old Sun's legacy form. An example of
this file can look like:
<table >
<tr><td class=tdc>
<pre><code id="cmd">servlet./app-bin/tree/*.code=rogatkin.servlet.Dispatcher
servlet./app-bin/tree/*.initArgs=properties=src\javaarchitect\servlet\treeview.properties
servlet./app-bin/chat/*.code=rogatkin.chatservlet.ChatServlet
servlet./app-bin/chat/*.initArgs=properties=C:\\Projects\\ChatServlet\\chatservlet.properties
servlet./app-bin/lunch.code=javaarchitect.servlet.mishka.Friday
servlet./app-bin/lunch.initArgs=properties=src\javaarchitect\servlet\mishka.properties
</code></pre>
</td></tr>
</table>
Here <code>servlet.</code> is just keyword. Next part is servlet URL mapping and
servlet name at the same time. Mapping notation was changed since 1.93 to match servlet specification,
so /* should be added to old notation. Next part is dot (.) separator of servlet class name, when <code>code</code> used,
or init arguments comma separated name=value pairs when <code>initArgs</code> is used.</td>
  </tr>
  <tr><td class="style2"><b>r</b></td>
     <td id="cmd">specifies realm file. A format of this file looks like:
<table class=tdc>
<tr><td>
<pre><code>realmname=path,user:password</code></pre>
</td></tr>
</table>Path has similar notation as servlet mapping URL.</td>
  </tr>
  <tr><td class="style2"><b>a</b></td>
     <td id="cmd">specifies aliases definition file. Every line of the file 
specifies one alias entry starting from keyword from=webpath;dir=directory_in_filesysten_to_map, for example:
<table >
<tr><td class=tdc>
<pre><code>from=/;dir=src\javaarchitect\servlet\tree\resource
from=/pool;dir=data</code></pre>
</td></tr>
</table></td>
  </tr>
  <tr><td class="style2"><b>b</b></td>
     <td id="cmd">bind address, if your machine has several IP addresses, then you can
specify which one to use</td>
  </tr>
  <tr><td class="style2"><b>k</b></td>
     <td id="cmd">backlog size, by default 50, but can't be less than 2</td>
  </tr>
  <tr><td class="style2"><b>nohup</b></td>
     <td id="cmd">server doesn't expect any terminal window, can be only killed to
stop</td>
  </tr>
  <tr><td class="style2"><b>c</b></td>
     <td id="cmd">specifies a web path of <a href="cgi.html">CGI</a> scripts directory</td>
  </tr>
  <tr><td class="style2"><b>e</b></td>
     <td id="cmd">provides session timeout in minutes and can be negative. Negative value
won't start session cleaning thread and will use a persistent session cookie</td>
  </tr>
  <tr><td class="style2"><b>m</b></td>
     <td id="cmd">limits max number of active sessions by a specified value,
        can't be less than 10. Default value is no limitation</td>
  </tr>
  <tr><td class="style2"><b>l</b>[<b>ar</b>][f format_string]</td>
     <td id="cmd">specifies to log accesses with optionally logged user-<b>a</b>gent and
<b>r</b>eferer HTTP headers. When <strong>f</strong> modifier specified a format string
    has to follow which is a valid format string for java.text.MessageFormat class.
    Positions of parameters are:
    <table >
    <tr><td class=tdc>    <ol start=0>
    <li>IP</li>
    <li>RFC 1413 identity</li>
    <li>Remote user</li>
    <li>Timestamp</li>
    <li>Request method</li>
    <li>Request Resource</li>
    <li>Request Protocol</li>
    <li>Result code</li>
    <li>Bytes transferred to client</li>
    <li>Local port</li>
    <li>Referer (if requested)</li>
    <li>User agent (if requested)</li>
    </ol>
</td></tr>
    </table></td>
  </tr>
  <tr><td class="style2"><b>g</b></td>
     <td id="cmd">requests rolling log file after reaching parameter specified line numbers. Can't be made less than 1000, and no rolling used if not specified or parameter is 0. Since 1.102</td>
  </tr>
  <tr><td class="style2"><b>w</b></td>
     <td id="cmd">provides web app deployer class name, by default used r<i>ogatkin.web.WarRoller</i></td>
  </tr>
  <tr><td class="style2"><b>j</b></td>
     <td id="cmd">JSP servlet class, <i> org.gjt.jsp.JSPServlet</i> is default; extra init parameters can be specified 
for JSP servlet; 
syntax of parameters is <kbd>-class_name_perfix.param_name param_value</kbd>; note that value 
can contain variables like %context% and %deploydir% substituted by actual 
values respectfully. Another substitution happens for %classloader% by 
a 
name of a servlet context attribute keeping an instance of a class loader used for a web 
application deployment (available from version 1.15). Version 1.22 and above 
introduced another variable %classpath% which substituted by class path used for 
loading servlet</td>
  </tr>
  <tr><td class="style2"><b>nka</b></td>
     <td id="cmd">no keep alive (server uses keep-alive by default)</td>
  </tr>
  <tr><td class="style2"><b>kat</b></td>
     <td id="cmd">keep alive timeout interval in seconds, default is 30</td>
  </tr>
  <tr><td class="style2"><b>mka</b></td>
     <td id="cmd">max number of a connection use in keep-alive</td>
  </tr>
  <tr><td class="style3"><b>sh</b></td>
     <td id="cmd" class="style4">HTTP only attribute for session cookie. Can improve a security. A session
     cookie doesn't carry this attribute by default. Since 1.90</td>
  </tr>
 <tr><td class="style3"><b>ss</b></td>
     <td id="cmd" class="style4">Secure only attribute for session cookie. Can improve a security. A session
     cookie doesn't carry this attribute by default. Since 1.99</td>
  </tr>
  
  <tr><td class="style3"><b>sp</b></td>
     <td id="cmd" class="style4">persistence for sessions, TJWS is capable storing sessions data 
in a portable format and reload them between restarts or nodes of a cluster. Do 
not use this option if sessions contain 
sensitive, not serializable, or bulky data</td>
  </tr>
  <tr><td class="style2"><b>err</b></td>
     <td id="cmd">allows to use own or standard error print stream. If there is no 
following parameter class name then used <i>System.err</i> as error print 
stream. If a parameter specified, then it's considered as a class name 
compatible for assignment to <i>PrintStream.</i> Such class will be instantiated 
and used for error redirection</td>
  </tr>
  <tr><td class="style2"><b>out</b></td>
     <td id="cmd">allows to define own class which will handle log needs. This 
class has to be assignment compatible with <i>PrintStream. </i>An attempt of 
instantiation of the class with default constructor happens at TJWS startup, so 
the class has to be available in startup class path. This class will handle err 
stream too unless <b>-err</b> option is specified. TJWS includes class <i>
Acme.Utils$DummyPrintStream</i> for disabling any log printing. (since 1.26)</td>
  </tr>
  <tr><td class="style5"><b>d</b></td>
  <td id="cmd" class="style6">Log file directory for default logging, <code>System.getProperty("user.dir")</code> is used by default (since 1.30)</td></tr>
  <tr><td class="style2"><b>z</b></td>
     <td id="cmd">defines max number of created threads in a thread pool used for 
servicing requests. 20 used when the parameter not defined. 0 or negative - do 
not use thread pool</td>
  </tr>
  <tr id="cmd"><td class="style2"><b>socketFactory</b></td>
     <td id="cmd">specifies class name of socket factory and used for setting
a secure connection. (deprecated since 1.30)
<p>It accepts also any freely specified options in form -option_name option_value.
Such options passed without checking to a custom server socket factory
implementation and other modules of the server</td>
  </tr>
  <tr><td class="style2"><b>acceptorImpl</b></td>
     <td id="cmd">specifies a class name of a concerete <em>Acceptor</em>
        implementation. Default is Acme.Serve.SimpleAcceptor (since 1.31). See note above about processing
        additional connection parameters. Since 1.30</td>
  </tr>
  <tr><td class="style2"><b>dataSource</b></td>
     <td id="cmd">specifies a data source properties file location. Supported by rogatkin.app.Main
         run module. Since 1.30<br>
         
         This option is valid only for app server runner (class rogatkin.app.Main)<br>
         TJWS  .war deployer can process also context.xml file
         supplied in META-INF directory of application .war for same purpose. Since 1.98.
         A property file can contain the following properties:
         <ul>
         <li> <i>jndi-name</i> (required) - under this name the data source will be registered in JNDI
     if name starts with <strong>jdbc</strong>, then prefix <i>java:comp/env/</i> will be added when registered in JNDI.
 <li> <i>driver-class</i> - class name of JDBC driver
 <li> <i>url</i> - JDBC connection URL
 <li> <i>user</i> - connection user
 <li> <i>password</i> - connection password
 <li> <i>pool-size</i> - max number of allocated connections, 0 = no size limitation, -1 = no pool used 
 <li> <i>access-timeout</i> - timeout in ms before getting an exception on connection request when no connections
 are available, 0 means wait forever
 <li> <i>driver-class-path</i>  - defines class path to a driver archive and/or a 
     connection validator class, unless they are already defined&nbsp; in a boot classpath
 <li> <i>prob-query</i> - a query to run against a given connection to verify a 
     validity, There are two predefined values <i>IsValid</i> and <i>isClosed</i> 
     used for calling corresponding methods of JDBC connection 
     instead of a query. Note that <code>isValid()</code> method is available in JDBC 3.
 <li> <i>exception-handler</i>- a class with static public <i>boolean</i> method <strong>validate</strong> and two parameters of type <i>SQLException</i>, and <i>Connection</i>
             returning <strong>false</strong>  when the connection has to be discarded after the SQLException
            </ul> 
            Here is a quick map between properties names and context.xml Resource tag attributes:
            <table>
            <tr><td>jndi-name</td><td>name</td></tr>
            <tr><td>driver-class</td><td>driverClassName</td></tr>
            <tr><td>url</td><td>url</td></tr>
            <tr><td>user</td><td>username</td></tr>
            <tr><td>password</td><td>password</td></tr>
            <tr><td>pool-size</td><td>maxActive</td></tr>
            <tr><td>driver-class-path</td><td>driverClassPath</td></tr>
            <tr><td>prob-query</td><td>validationQuery</td></tr>
            </table>
             </td>
  </tr>
</table>
    <p>
        TJWS processes several Java System level definitions in addition to command line arguments
        specified as JVM's -D arguments:</p>
<p>
    <strong>tjws.serve.log.encoding</strong> - this definition specifies encoding 
    used for log messages, it can be very convenient to debug multi lingual web 
    applications.</p>
<p>
    <strong>tjws.proxy.ssl</strong> - this definition specifies that server should process
    X-Forwarded-xxxx headers for calculation remote and server addresses. If value of the property 'y',
    then SSL is considered to be handled by a proxy server. (Since 1.71)</p>
<p>
    <strong>java.protocol.handler.pkgs</strong> - this definition is used by SSL 
    socket factories implementations to define a different protocol handler 
    packages, than standard com.sun.net.ssl.internal.www.protocol</p>
    
        <h4>The following definitions are used by J2EE servlet/deployer module:</h4>
    <p>
        <strong>tjws.webappdir</strong> - specifies path to web application war files location
        for automatic deployment. By default TJWS_ROOT/webapps directory is used.</p>
    <p>
        <strong>tjws.webclassloader</strong> - specifies custom class loader class name used for loading classes
          from war file. The class loader must to have constructor accepting parameters as <kbd>URL[]</kbd> and 
          <kbd>ClassLoader</kbd>. Since 1.83</p>
    <p>
        <strong>tjws.wardeploy.warname-as-context</strong> - see details below.</p>
    <p>
        <strong>tjws.wardeploy.as-root</strong><i>[.virtual_host_name]</i> - defines context name/war name used for deploying
        in root, e.g. <em>-Dtjws.wardeploy.as-root=&lt;app_context/war_name&gt;</em> If virtual host name part is presented, then it defines a fully qualified
        host name for which the root context is set. (Since 1.71)</p>
        <a name="virtual"></a><p>
        <strong>tjws.virtual</strong> - defines deployment of web applications in virtual hosting environment. <br>
        </br>
        When the definition is specified, TJWS J2EE web applications deployer looks in all subdirectories
        under automatic web application deployment directory and considers directory name as virtual
        host name and directory content as automatic web application deployment directory for
        corresponding virtual host.<br></br>
        For example:
        <pre>
           TJWS_ROOT/webapps
               www.travelspal.com
                   travelspal.war
                   webfolder.war
               www.7bee.org
                   sqlfair.war
                   webchat.war
               xumster.war
               jaddressbook.war</pre>           
        
        <br> </br> (Since 1.71)
        </p>
    <p>
        <em>class_name</em>.<strong>debug</strong> - this definition is passed to JSP provider
        for allowing debug specified class name.</p>
    <p>
        <strong>tjws.fileservlet.usecompression</strong> - this definition advises to compress text 
        content response when a client can accept it. To make this suggestion per application,
        use <strong>tjws.webapp.<em>&lt;context_name&gt;</em>.compressresponse</strong> Since 1.31</p>
    <p>
        <strong>tjws.fileservlet.suppressindex</strong> this definition advises the file servlet
        to do not show content of a directory when an index file can't be found. Since 1.96</p>
    <p>
        <strong>tjws.wardeploy.dynamically</strong> - this definition advises J2EE deployer for
        monitoring .war files updates and redeploy corresponding applications without the server
        restart. Optional value of this definition specifies time interval in seconds between checks. Since 1.50</p>
     <p>
        <strong>tjws.wardeploy.noincremental</strong> - instructs TJWS redeploy entire web application when newer version of
        .war detected. Default is incremental deployment overriding only older files and not touching added. Since 1.93</p>
    <p>
        <strong>tjws.webapp.<i>context name</i>.init.timeout</strong> - specifies init timeout in seconds of 
        corresponding web application by context name, use * if you need to define it for all contexts</p>
    <p>
        <strong>tjws.webapp.<i>context name</i>.threadpoolsets</strong> - specifies core, max threads, 
        and queue size a thread pool of corresponding web application by context name, use * if you need to define it for all contexts. Since 1.80</p>
    <p>
        <strong>tjws.webapp.debug</strong> - value yes turns on additional debug print outs for J2EE deployed apps</p>
    <p>
        <strong>tjws.app.orb.arguments</strong> - this definition can provide comma
        separated parameters used for ORB initialization. Since 1.50</p>
    <p><strong>tjws.app.main</strong> - name of main class started with offering app server services. TJWS supports not
    only web applications, any desktop Java application can get benefits of app server services
    as JNDI and container managed JDBC connections. Since 1.50
    </p>
    <p><strong>tjws.app.main.classpath</strong> - class path for main application class specified
    as definition <i>tjws.app.main</i>, unless the main class can be resolved from boot class path. Since 1.50
    </p>
    <p><strong>tjws.app.main.striprightparam</strong> - specifies a position in command line arguments which have to be not
    passed to a main class defined in <i>tjws.app.main</i>. It gives flexibility of separate
    command line arguments used by launched application and app server services itself. Since 1.50
    </p>
    <p><strong>tjws.app.main.stripleftparam</strong> specifies a position to cut from left. See description of
    <i>tjws.app.main.striprightparam</i>. Since 1.50
    </p>
    <p><strong>tjws.websocket.container</strong> "true" value specifies that websocket end points can be deployed in scope of TJWS itself (not in scanning from a .war packaged web application)
    
    TJWS class path is used for such deployment. The option is useful for embedded usage of TJWS. Since 1.111
    </p>
    <p>
        Since TJWS has a long history it supports as a legacy way of deployment and configuration
        of servlets as a new .war (web.xml) based. The legacy deployment uses property 
files, like servlets.properties and aliases.properties. J2EE way is based 
on web.xml and config.xml files. When a legacy way used, the server can keep a minimal 
configuration and run on JDK version started from 1.2 (Actually the current version has 9 JDK
        1.4 dependencies which can be easily corrected if JDK 1.2 is a real requirement). Websocket
        extension deployment uses the modern annotated classes mechanism.
        </p>
    <h4>    
    <a name="security"></a>Security</h4>
<p>Security becomes more important nowadays, so I decided to add SSL support to
TJWS. Thanks JSSE for making that fairly easy. Here some tips how to install SSL
support to the server.</p>
<ul>
  <li><i>Download JSSE from Oracle's website or use JDK1.4.2 or later already including this extension.</i></li>
  <li><i>Generate certificate using command like: keytool -genkey -keypass 123456 -storepass 123456 -keyalg RSA<br>
    Read more details in keytool documentation when you need a certificate signed
    by CA. Tomcat's <a href="http://tomcat.apache.org/tomcat-4.1-doc/ssl-howto.html">how-to for SSL</a> can be useful also.</i></li>
	<li><i>Add command line parameter -socketFactory socket_factory_class_name 
	and enjoy the show.</i></li>
</ul>
<p>There are three SSL supporting socket factories packaged with TJWS - <i>Acme.Serve.SSLServerSocketFactory </i>
,<i> rogatkin.web.DoubleHeadSocketFactory</i> (available from v 1.17), and 
<i>rogatkin.wskt.SSLSelectorAcceptor</i> (available from v 1.110). First is recommended to use 
with core TJWS, when second with J2EE deployment module since it provides 
supporting http and https at the same time and requires Java 5+. Third is required for websocket configuration. 7Bee script 
contains examples of usage two factories. Command <kbd>bee -Dsecure=true</kbd> runs TJWS using SSLSelectorAcceptor, and <kbd>bee -Ddoublehead=true</kbd> runs  DoubleHeadSocketFactory. 
Additional command line parameters can be specified with each factory like :</p>
<ol>
	<li><u>algorithm</u> - encryption algorithm, SUNX509 when not specified</li>
	<li><u>clientAuth</u> - requires client authentication, false when not 
	specified</li>
	<li><u>keystoreFile</u> - key store file path, user_home/.keystore by 
	default</li>
	<li><u>keystorePass</u> - key store password, empty string when not 
	specified</li>
	<li><u>keystoreType</u> - type of key store, Oracle's JKS when not specified</li>
	<li><u>protocol</u> - secure protocol, TLS when not specified</li>
	<li><u>backlog</u> - backlog value, 1000 by default</li>
	<li><u>ifAddress</u> - bind to specified address</li>
	<li><u>port</u> - bind to specified port</li>
	<li><u>ssl-port</u>&nbsp; SSL port (only for <i> DoubleHeadSocketFactory and rogatkin.web.DualSocketAcceptor
    </i>)</li>
	<li><u>ssl-backlog</u> backlog size (only for <i> DoubleHeadSocketFactory and rogatkin.web.DualSocketAcceptor</i>)</li>
</ol>
<p>
    <span style="text-decoration: underline">Note that</span> some secure socket options will override options specified in a 
regular way.</p>
<p>You may also adding your own socket factory implementations. See the 
packaged socket factories as a reference implementation.</p>
    <p>
        Starting from 1.30 Socket Factory concept was replaced by Acceptor. It allowed to
        use Selector based processing requests with 10% improved performance and required for websocket. 
        Five concrete Acceptor implementations are available:</p>
    <ul>
        <li>Acme.Serve.SelectorAcceptor - non secure, channel based implementation (use with websocket in non blocking IO mode).</li>
        <li>rogatkin.wskt.SSLSelectorAcceptor - secure, channel based implementation (use with websocket in non blocking IO mode).</li>
        <li>Acme.Serve.SimpleAcceptor - non secure, server socket based implementation, is used by
            default.(since 1.31)</li>
        <li>Acme.Serve.SSLAcceptor - secure, SSL socket based implementation.</li>
        <li>rogatkin.web.DualSocketAcceptor - combined secure and non secure sockets implementation.</li>
    </ul>
    <p>
        The author appreciates if you can share own implementations of Acceptor.</p>
    <a name="j2ee"></a><h5>
        J2EE deployment
    </h5>
    <p>
        For J2EE deployment you need to make sure that war.jar is specified in classpath
        when you start the server. It will create webapps directory (configured location) where you can put your
        .war files for auto deployment. Deployment gets updated at startup absorbing  any changes from source .war file,
        however all changes done in target deployment directory are preserved. TJWS can monitor also source .war changes
        during runtime when <strong>tjws.wardeploy.dynamically</strong> is specified, and redeploy 
        application if changes were detected. <i>server.xml</i>
        isn't supported and most of server specific parameters have to be specified as command
        line arguments, or stored in a flat file as <i>cmdparams</i>. All examples of startup
        scripts are presented in directory bin of a distributive archive. Most of examples
        contain both ways of server configuration and application deployment. Note that
        deployment descriptor (<i>web.xml</i>) parameter <i>display-name</i> defines a context
        path of a deployed web application. If you want to have context path matching to
        .war name then add system property <strong>tjws.wardeploy.warname-as-context</strong> set to yes.
        For command line it will look like -Dtjws.wardeploy.warname-as-context=yes . (Since
        1.24) To prevent application update at startup time you need to remove corresponding
        .war from deployment directory. It gives also a way to deploy web applications without
        .war just manually create web app directory structure. Check section '<a href="#embedable">Embeddable
            application</a>' for more options of deployment and distribution of applications.</p>
    <p>
        Supported web.xml deployment tags are:</p>
<ul>
  <li>context-param - yes</li>
  <li>filter - yes</li>
  <li>filter-mapping - yes</li>
  <li>listener - yes</li>
  <li>servlet - yes</li>
  <li>servlet-mapping - yes</li>
  <li>session-config - yes</li>
  <li>mime-mapping - yes</li>
  <li>welcome-file-list - yes</li>
  <li>error-page - yes</li>
  <li>taglib - by JSP provider</li>
  <li>resource-env-ref - yes</li>
  <li>resource-ref - yes</li>
  <li>security-constraint - in work</li>
  <li>login-config - in work</li>
  <li>security-role - in work</li>
  <li>env-entry - yes</li>
  <li>ejb-ref - no</li>
  <li>ejb-local-ref - no</li>
  <li>new JSR315 - yes</li>
  <li>new JSR356 - yes</li>
  <li>multipart-form - this is non standard tag carries a function of a casual multipart request processing similar to Resin. Since 1.112</li>
</ul>
<a name="appservices"></a>
<h4>App server services</h4>
<p>
TJWS includes app server services module. It takes some usable shape from version 1.50. There are two services offered:</p>
<ul>
<li>Data source with connection pooling
<li>JNDI
</ul>
<p>For using these services app.jar has to be in class path, or/and used for starting the server. The bin directory includes an example of starting TJWS with app server services on. Data sources get configured from properties files specified as <strong>�dataSource</strong> command line option. JNDI properties as context factory and JNDI URL get pre-populated as 
    <i>rogatkin.app.SimpleJndi</i> and <span class="style1">http://localhost:1221
    </span>correspondingly, unless they are defined as system properties. JNDI is capable to register local and CORBA objects. First running JNDI takes care of JNDI master repository, and all following JNDI starts will be registered in the master repository. If the master repository's gone, then all clients won�t be capable to register own CORBA objects or access them, until the repository is back. There is no persistence for stored references, so you should 
 do a defended programming and reregister references in case of crashing the master repository. </p>
<h5>context.xml</h5>
<p>Data source definition can be specified in context.xml placed under META-INF directory of .war structure. (since 1.98)</p>
    <h5>
        3.0 Deployment descriptor</h5>
<p>Multiple URL patterns can be defined anywhere. Some other features are under 
consideration. Work on 
processing annotations in a servlet code started. Async and multi part features are supported.</p>
   <a name="jasper"></a> <h5>
        Jasper JSP provider integration</h5>
	<p>You can use Jasper JSP provider for servicing JSP pages inside an 
	application. Since the original Jasper is a bit bulky for TJWS taste, it's 
	recommended to strip it to a manageable size. TJWS distribution 
	includes instructions how to modify, build, and connect Jasper in 
	<a href="./jasper.html">jasper.html</a> of <i>webroot</i> directory Jasper of respectful Tomcat versions 5.x, 6.x (since 1.28), and 7.x (since 1.83) is supported.
    </p>
    <a name="service"></a><h4>
        Running it as a service on all Windows platforms</h4>
<p>You can run the server of the  version (&gt;1.42/1.7) as Windows service. File
<b>servservice.exe</b> added to the distribution. I wrote this service for JDK
1.4. It works without a change for Java 5 and 6. C source code of service implementation is included.  A service starter considers that all TJWS files reside in the same
directory specified at installation of the service. .jar files can be in sub
directory <i>lib</i>. Command line parameters have to be specified in <i>cmdparams</i>
file. Use -nohup switch to avoid a console read attempt. To get help line, run <font face="Courier New" size="2">servservice.exe
-help</font>. Parameterless version of servservice.exe is considered as a
service.</p>
<p>Note that arg[0] which supposes to give a fully qualified name of a service 
executable on some versions Windows ((like XP) doesn't do that. For this reason 
you have to specify a fully qualified path as the last parameter of an 
installation command.
There is no requirements to have <b>servservice.exe</b> in the same
directory where TJWS is. Here is an example of an installation command:<br>
<kbd>servservice.exe -install "C:\Project Files\tjws&quot; &quot;C:\Project Files\gnujsp\lib\jspengine.jar&quot; TinyJavaWebServer TinyJavaWebServer "C:\Project Files\tjws\servservice\Debug\servservice.exe" -Dtjws.wardeploy.warname-as-context=yes </kbd></p>
<h4>Running it as a service on all Linux platforms</h4>
<p>A Linux service script example <abbr>tjwserv</abbr> is provided in bin directory of the distribution archive.
It has to be edited to reflect particular TJWS installation directory structure. The script has to be stored in
<kbd>/etc/init.d/</kbd> location. Use command <kbd>update-rc.d tjwserv defaults</kbd> to enable the service.
You can control it using command <kbd>service tjwserv &lt;start|stop|restart&gt;</kbd>. Look in Raspberry PI
setup section for enabling service on Arch Linux and other systems using systemd.</p>

<a name="embedable"></a>
    <h4>
        Embeddable application</h4>
<p>Recently, a new type of application appeared on the market. After starting an 
application is launching a browser which represents its UI. This approach has many advantages and becomes more 
popular and wider used. The
Miniature Java Web Server is a right tool for creation such kind of application. 
<a href="http://prdownloads.sourceforge.net/searchdir/finesearch.jar?download">Download</a>
and double click JAR in Explorer or launch it from a terminal typing <kbd>java -jar
<a href="http://prdownloads.sourceforge.net/searchdir/finesearch.jar?download">
finesearch.jar</a></kbd>,
then point browser to <a href="http://localhost:8080/finesearch">http://localhost:8080/finesearch</a> 
and enjoy the web interfaced application. Starting from version 
1.21 TJWS includes a launcher of a .war packaged application from command line or a 
start script. The feature is very similar to used by <u>Winstone</u>.&nbsp; Use:<br>
<kbd>java -jar webapplauncher.jar war_file_name [optional standard TJWS CLI 
parameters]</kbd><br>
for example:<br>
<kbd>java -jar webapplauncher.jar &quot;<a href="file:///C:/Project%20Files/finesearch/finesearch_app/finesearch.war">C:\Project Files\finesearch\finesearch_app\finesearch.war</a>&quot;</kbd><br>
Note if extra command line arguments are not specified, then TJWS will try to 
discover them from <i>cmdparams</i> located in a working directory.<br>
Version 1.22 and above makes launching Web UI application even more simpler. Web 
application .war can be packaged inside of TJWS .jar file allowing one click 
launch. To package web application .war with TJWS use target '<i>embedded</i>' of 
<a href="http://knitknot.info/download/7bee/bee-1.1.1.zip">7Bee 
build tool</a> and answer on few simple questions. For example:</p>
    
      <table border="1" width="100%">
        <tr>
          <td width="100%" bgcolor="#000000">
			<font color="#FFFFFF" face="Courier New" size="1">C:\Project Files\tjws&gt;<b>bee 
			embedded</b><br>
			Launcher's been built.<br>
			Enter command line arguments for app [-nohup -p 80]? <b>-p 80</b><br>
			Enter application .war file location?<b> C:\Project Files\finesearch\finesearch_app\finesearch.war</b></font></td>
        </tr>
      </table>
	As result finesearch.jar is created in lib directory which is launchable 
	using <kbd>java -jar finesearch.jar</kbd><br>When JDK 6 is used you can get 
it running in system tray, use <kbd>javaw</kbd> for JAR launching.<br>
<img border="0" src="./tjws_systray.jpg"><br>
	System tray menu will contain an item for going directly to an application 
	with web UI (since 1.24).<br>
	Use 7Bee target <i>asembedded</i>, when web application needs container provided
	JNDI and data sources. (since 1.50).
   
<h5>J2EE without application server</h5>
<p>TJWS gives a good possibility to create enterprise class J2EE applications 
without an expensive and heavy weight application server.
<a href="http://webbee.sf.net">WebBee library</a> will 
take care of SOA registry, MVC servlet framework with template based 
presentation layer, data persistence and 
much more. Check out <a href="http://resumefair.knitknot.info/">a demo</a> 
of a real application based on this approach. New generation of web application building blocks WebBee 
with annotated JDO and forms makes creation of rich application possible even for Android platform.</p>
<a name="embedded"></a><h4>
    Embedded usage</h4>
    <p>
        TJWS can be successfully used as a part of another Java application. Acme.Serve.Serve
        can be instantiated as a Java bean with following setting parameters in its public member
        <em>arguments</em> and log print stream in its public member <em>logStream</em>.
        Use method <strong>addServlet(..)</strong> for adding servlets. Note that
        server will do nothing without servlets. Default file (HTTPD) and cgi servlets can be added
        calling <strong>addDefaultServlets(...)</strong>. Server can be started calling
        method <strong>serve()</strong> and stopped calling <strong>notifyStop()</strong>.
        Note that <strong>serve()</strong> doesn't exit until a server runs, so stopping should be called
        from a separate thread, or serve() is ran in a separate thread.<br />
        A minimal application with embedded TJWS looks like:</p>
    <pre>public class Test {
	public static void main(String... args) {
		class MyServ extends Acme.Serve.Serve {
			// <i>Overriding method for <strong>public</strong> access</i>
                        public void setMappingTable(PathTreeDictionary mappingtable) { 
                              super.setMappingTable(mappingtable);
                        }
                        // add the method below when .war deployment is needed
                        public void addWarDeployer(String deployerFactory, String throttles) {
                              super.addWarDeployer(deployerFactory, throttles);
                        }
                        public void addWebsocketProvider() { <i>// add if plan to deploy websocket endpoints</i>
                            addWebsocketProvider(null); <i>// list of class path file components can be provided here</i>
                        }

                };

		final MyServ srv = new MyServ();
 		// <i>setting aliases, for an optional <strong>file servlet</strong></i>
                Acme.Serve.Serve.PathTreeDictionary aliases = new Acme.Serve.Serve.PathTreeDictionary();
                aliases.put("/*", new java.io.File("C:\\temp"));
		//  <i>note cast name will depend on the class name, since it is anonymous class</i>
                srv.<strong>setMappingTable</strong>(aliases);
		// <i>setting properties for the server, and exchangeable Acceptors</i>
		java.util.Properties properties = new java.util.Properties();
		properties.put("port", 80);
		properties.setProperty(Acme.Serve.Serve.ARG_NOHUP, "nohup");
		properties.setProperty("acceptorImpl", "Acme.Serve.SelectorAcceptor"); <i>// this acceptor is requireed for websocket support</i>
		srv.<strong>arguments</strong> = properties;
		srv.<strong>addDefaultServlets</strong>(null); <i>// optional file servlet</i>
		srv.<strong>addWebsocketProvider()</strong>;  <i>// enable websocket</i>
		srv.addServlet("/myservlet", new MyServlet()); // optional
		// the pattern above is exact match, use /myservlet/* for mapping any path startting with /myservlet (Since 1.93)
		Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
			public void run() {
				srv.<strong>notifyStop</strong>();
				srv.destroyAllServlets();
			}
		}));
		srv.<strong>serve</strong>();
	}
}
 </pre>
 <p>The File servlet without aliases definitions maps your file system directly to a web accessable one, so setting up aliases is recommended.</p>

 <p>J2EE servlet deployment is possible in an embedded usage. You need to assure
that JDK 1.5 or above is used and war.jar is in a class path of an
application.<br />

Add a line as below:
</p>
<pre>
      ((Test$1)srv).<strong>addWarDeployer</strong>(null, null);
</pre>
<p>
The default war deployer will look in directory "user.dir/webapps" and
deploy all wars there. You can redefine a deploy repository by setting
</p>
<code>
System.setProperty("tjws.webappdir", newDeployDirectory);
</code>
<p>
prior of calling addWarDeployer() </p>
<p>TJWS works perfectly on Android platform as embedded server enriching your Android application by
 a capability to receive uploads, check
 <a href="https://play.google.com/store/apps/details?id=rogatkin.mobile.app.lialichka" target="_blank">Kamerton</a> application using TJWS for uploading music to Android device.</p>
    
<a name="mobile"></a><h4>
    Mobile and appliance usage</h4>
    TJWS provenly runs on wide specter mobile devices as Sharp Zaurus, Windows CE/Mobile, all Android, and Blackberry platforms. Java
    gives great portability of TJWS between different mobile devices.
    <h5>
        Run it on Zaurus</h5>
<p>Zaurus version is currently retired, since Zaurus has been replaced by Android.</p>
<h5>Run it on Windows Mobile</h5>
<p>Since Microsoft dropped Java and allow to install only products from mobile store on Windows surface tablets, here is
no good possibility to run TJWS. So here is a plan to create Objective C and C++ library supporting core
functionality of TJWS to be able to run it on iOS and Windows Mobile platforms. </p>
<h5>Run it on Raspberry Pi</h5>
<p>TJWS is naturally created for running web applications on Raspbery Pi. It will outperform most of other application
servers on the platfrom including Jetty,  JBOSS and Tomcat. Start time for it is just around 11 seconds, when you can
 observe times close to 1 minute with 
other application servers. Here are few notes helping to start using it:</p>
<ul>
  <li>Debian "wheezy" is preferred as OS for Raspberry Pi and TJWS</li>
  <li>Download Oracle JRE marked as <strong>Linux ARM v6/v7 Hard Float ABI</strong></li>
  <li>If you use Linux "dd" utility on Ubuntu to transfer Debian image to SD card, then keep it mounted and
  use device name as <strong>/dev/sd</strong>c (last letter can be "b" for some systems)</li>
  <li>There <a href="http://www.savagehomeautomation.com/pi-jdk">is</a> a good resource for beatifying JRE installation</li>
</ul>
<p>If you plan to use Raspberry Pi mostly as server operating 24/7, then I recommend to install Arch Linux especially if your network connection is wireless.
Since Arch Linux specific is less covered on net, I prepared my own <a target="_blank" href="arch-raspi-java8.html">guide</a> which can help you start using
TJWS faster.<br>
Raspberry Pi development is certainly addicting, so if you are on same boat feel free to drop me a note.
</p>
<h5>Run it on Android devices</h5>
<p>TJWS provides Android packaging for run the server on Android devices. This packaging got name
<strong>Atjeews</strong> and provided as a separate download. Atjeews is also available at Google Play under same name. Atjeews is just a small server launcher
Java program. The server runs FileServlet against Android root directory "/". You can deploy
any web application on it just loading war files. Atjeews can be mapped to any port and supports SSL.
<div style="float:right"><img src="atjeews.png">&nbsp;<img src="atjeews_webfolder.png"></div>
 Since Android devices use  Dalvik JVM, you need to
convert all content of WEB-INF/lib and class directories of your web application to DEX format
 supported by Dalvik. Use DX tool for that.<br>
The following command will work:<br>
<kbd>dx --dex --output=&lt;original_jar_file&gt; &lt;dalvik(dex) jar&gt;</kbd><br>
Please note that your web
application has to be JDK 1.5 compatible since Android OS below version 3.0 supports only Java 1.5.

7Bee <a href="https://github.com/drogatkin/Atjeews/blob/master/bee-dexwar.xml">script</a> (7Bee <a href="https://github.com/drogatkin/7Bee">version</a> of 1.1.1 or above required) is availble for converting war files to format supported by Android platfrom.
The script is highly recommended to use when your web application includes JSP pages, since
the script take care of precompilation of JSP files and DEX converting. Atjeews is 
bundled with Jasper to run JSP. See more about Atjeews <a href="atjeews.html">here</a>.
 Since 1.83<br>
 Blackberry BAR Atjeews packaging added to version 1.95. It supposes also appearing in RIM AppWorld as a <strong>free</strong> application.
</p>
<h4>Run it on iPhone?</h4>
  <p> There are several options to run Java applications on iPhone and iPad. You will need to jail break your iPhone though.
  Since Steeve isn't with Apple anymore, there is a good chance for porting Davlik to iOS platfrom. I heard that iOS 9.0 (current is 8.0) will have Java included</p>

<a name="proxy"></a>
<h3>Use TJWS as proxied</h3>
<p>TJWS can be used with proxy servers. Definition <strong>tjws.proxy.ssl</strong>
can be specified to correctly determinate remote host and access protocol.
<br></br>
To use Apache as a proxy server you can:
<ol>
<li>make sure that mod_proxy enabled in httpd.conf</li>
<li>add below directives in httpd.conf
<pre>
   ProxyRequests On
   ProxyVia On
   ProxyPass /context_path/ http://tjws_host:&lt;TJWS port&gt;/web_app_context/
   ProxyPassReverse /context_path/ http://tjws_host:&lt;TJWS port&gt;/web_app_context/
# for pushing authentication
   RewriteEngine on
   RewriteBase /

   RewriteCond %{REMOTE_USER} !=""
   RewriteRule .* - [E=E_USER:%{REMOTE_USER}]

   RequestHeader set my_new_header %{E_USER}e
</pre>
</li></ol> 
<br>Another example of Apache configuration to use proxied TJWS as virtual host:
<pre>
&lt;VirtualHost *:*&gt;
ProxyPreserveHost On
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
ServerName www.tjws.com
&lt;/VirtualHost&gt;
</pre>
To use <strong>Nginx</strong> as a proxy server :
<pre>
    server {
        listen       80;
        server_name  localhost;
...
        location / {
            proxy_pass        http://localhost:8080;
            proxy_set_header  x-Forwarded-for  $remote_addr;
            proxy_set_header  X-Forwarded-Host $host;
        }
...        
</pre>
Please note that Nginx doesn't support keep alive for proxy requests yet, so you can observe some performance degradation.
</p>
  <h4><a name="download"></a>Download</h4>
<p>Please 
<a href="http://sourceforge.net/projects/tjws/files/">download</a> 
(version 1.114)
</p>

<p>Visit Atjeews at <a href="https://github.com/drogatkin/Atjeews" target="_blank">GitHub</a> for Android version of the server and download APK at
 <a href="https://play.google.com/store/apps/details?id=rogatkin.mobile.web">Google Play</a>.
</p>
<p><a href="https://github.com/drogatkin/TJWS2/tree/master/1.x" target="_blank">Sources</a>  of TJWS are available on GitHub</p>
<p><font color="#800000">Note:</font> Base TJWS is Java 2 (JDK 1.2) compatible, SSL 
module requires extra classes introduced in JDK 1.3-1.4. Base TJWS runs also on servlet specification 2.3, when
the rest of server is 3.1 version compatible. It makes building of TJWS a bit tricky. Some methods originally introduced in
TJWS are conflicting with JSR 315, so the author is looking how to eliminate this conflict with a minimal impact
of backward compatibility. J2EE war deployment 
requires Java 5 (JDK 1.5, 1.6, 1.7, or 1.8). If you would like to make own build, then you will need to download <a href="https://github.com/drogatkin/7Bee">7Bee</a> Java
based build tool. The env.xml assumes target 1.4 for TJWS and 
<font color="#FF0000"><b>1.7</b></font> for the 
rest. It may need being edited to provide SDK paths and targets. Modify variable '<i>j2ee 
target version</i>' in <i>env.xml</i> to 1.5 to avoid using System tray feature 
of JDK 1.6 and up. Specify env.xml variable '<i>android</i>' as <strong>yes</strong> to compile the server to run on <strong>Android</strong> devices (since 1.83). App servers features are not supported for Android though.
Since a build tool is a matter of personal taste, you can
use any other favorite build tools.</p>
    <p>
        Attention POSIX systems users, the distributive archive has access attribute
        not set, so execute <code>chmod -R +rwx WebServer</code> after unpackaging WebServer-nnn.zip</p>
<p>Zaurus version <a href="http://prdownloads.sourceforge.net/tjws/WebServerZaurus.zip?download">get here</a> and <a href="http://prdownloads.sourceforge.net/tjws/wsz_1.0_arm.ipk?download">.ipk
version</a> (use kill to stop)</p><a name="version"></a>
<h5>Last changes history</h5>
<font size="2">
<ul>
  <li>nohup option</li>
  <li>getSession() never <b>null</b> fix pointed by Warren E. Downs</li>
  <li>messed sessions fix when
    browser sends more than one session cookies</li>
  <li>session persistence between server re-runs (here are some 
	issues when classes loaded under WEB-INF/..)</li>
  <li>fixes realm not got applied to servlets, hanging when
    accessed reserved device, like con:, prt: pointed by users (Niel Markwick,
    and others)</li>
  <li>added J2EE web app deployment and JSP
    support (JASPER) as a separate module</li>
  <li>support of filters and listeners, requested by Argan</li>
  <li>keep-alive support, requested by Torben Bruun</li>
	<li>err option to keep System.err unchanged or customize it, 
	requested by Xavier</li>
	<li>many keep-alive fixes came from 
	Martin Egholm Nielsen</li>
	<li>fixes in web app servlet most reported by Nicolas Prochazka</li>
	<li>supporting HTTP and HTTPS transports in the same instance</li>
	<li>exit out of serve() by Andr� Kischkel</li>
	<li>thread pooling for servicing requests</li>
	<li>unavailable, and path pattern related fixes</li>
	<li>web app launcher including embedded .war</li>
	<li>JSP engine with spec 2.0/2.1 support as Japser</li>
	<li>filter for include, forward, and error. Multiple URL patterns</li>
    <li>HTTP Range request support for file servlet</li>
    <li>added Response Buffer and Request Dispatcher support in base server</li>
    <li>flexible support of server sockets including Selector based</li>
    <li>default log directory by Italia Roberto</li>
    <li>compression of text content by file servlet</li>
    <li>stronger security for session id</li>
    <li>fix: not eating unconsumed part of input stream for keep-alive connection (reported by Bill Burke@redhat)</li>
    <li>dynamic redeploy advised by poll results</li>
    <li>data sources and connection pooling advised by poll results</li>
    <li>missed processing of charset in POST request pointed by Jack</li>
    <li>virtual host by ganesan</li>
    <li>closing all connections at stop requestedd by Weinan Li@redhat</li>
    <li>JSR 315 <a href="http://www.slideshare.net/ALDAN3/server-side-push-in-aldan-3" target="_blank">Comet</a> support requested by Ivan Voronov</li>
    <li>Base server vulnerability related directory transversal using '..' pointed by Jo�o Sampaio</li>
    <li>Android compatibility of war deployment requested by Alex Xin</li>
    <li>Adjustung behavior matching to servlet specification done by Andreas</li> 
    <li>Using servlets mapping URL patterns matching to servlet specification including extensions mapping, by Bruno B </li>
    <li>Accurate handling keep allive by Andreas</li>
    <li>Proper freeing resources in CGI servlet by Frank</li>
    <li>SSL handler default class updated  by Jan</li>
    <li>Reliable detection of chunked encoding by Darren</li>
    <li>JSR 356 (websocket) by Robert</>
</ul>
 </font>
<a name="apps"></a><h4>Tested web applications</h4>
<p>I use TJWS primary for my business, however I verified functionality of some 
popular web applications. Here are just few of them:</p>
<ol>
	<li>Apache Slide (WebDav) and also WebDav servlet from GitHub</li>
	<li>jCVSWeb/jCVSServlet 1.41/1.01 (CVS web front-end)</li>
	<li>Pebble 2.2 (Blogger solution)</li>
	<li>DaveNPort 0.9.10 (Samba web front-end)</li>
        <li>Apache Axis2 1.0</li>
    <li>JASIG - single sign on service</li>
    <li>SimpleCaptcha </li>
    <li>Quercus&reg; (PHP engine)</li>
    <li>Apache Myfaces</li>
    <li>MetricStream EGRCP</li>
    <li>Google Web Toolkit (GWT)</li>
    <li>Stripes (JSP framework)</li>
    <li>Red5 (Streaming media server)</li>
    <li>OIOSAML.java SAML SSO servlet filter</li>
    <li>IBM's WeatherServer (Comet)</li>
    <li>JEExplorer from Denmark</li>
    <li>VAADIN another flavor of popular GWT</li>
    <li>Javamelody enterprise application monitoring and profiling tool</li>
    <li>Music Barrel - a music jukebox for Raspberry PI and PC</li>
</ol>
<a name="build"></a><h4>Build Tool</h4>
<p>
    TJWS is proudly built using most <u>sophisticated</u> Java build tool <b>7Bee</b>.
The tool is available in sources at <a href="https://github.com/drogatkin/7Bee" target="_blank">GitHub</a>. Another build tools can be used as well, although I support 7Bee only. 
 There is also no way to convert .war files to be deployed on Android, than using 7Bee. The following values needed to be provided in env.xml to build TJWS:</p>
    <ol>
        <li>SERVLET_LIB - fully qualified path to servlet.jar or other lib/directory containing
            JSS 2.3 classes</li>
        <li>SERVLET_LIB_30 - fully qualified path to servlet.jar or other lib/directory containing
            JSS 3.0 classes</li>
        <li>SERVLET_SRC - fully qualified path to sources of JSS classes, used only for packaging
            text resources in launcher packaging and can be omitted, unless launcher has to be built</li>
        <li>SERVLET_BUILD - fully qualified path to binaries of classes of JSS, used only for packaging JSS
            in launcher packaging and can be omitted, unless launcher with JSP has to be built</li>
        <li>JSP_LIB - fully qualified path to jsp.jar or other lib/directory containing JSP API classes</li>
        <li>WEBSOCKETS_CLIENT_LIB, and WEBSOCKETS_SERVER_LIB - fully qualified pathes for JSR 356 API client and server
          jars respectfully</li>
    </ol>
<font color=red>Note:</font> environment variables for versions prior 1.28 are slightly different.
    <a name="vm"></a>
<h4>JVMs</h4>
<p>TJWS was tested with most popular JVMs under Windows, Linux, Mac OS, and Solaris 
platforms and also on mobile platforms as Sharp Zaurus, Android, and Windows Mobile. 
Oracle, IBM J9, JRocket, Open JDK, Dalvik,
    and GNU VMs are capable to run TJWS.</p>
<a name="copyright"></a><h4>Copyrights</h4>
<p>The Miniature Java Web Server carries all copyrights of the original author
as stated in the license you can find in any source file.</p>
<h5>License</h5>
<p>The Tiny Java Web Server inherited BSD like license from the original
code, check any source file for details.</p>
<a name="support"></a><h4>Support</h4>
<p>I provide support of the server on voluntary basis. Feel free to send bug report on enhancement request. I also provide consulting service
related to creation of web 2.0 J2EE scalable applications. See an example <a href="http://resumefair.knitknot.info">ResumeFair</a></p>
<h5>Discussion forum</h5>
<p>Feel free also to share your concerns, questions, and discoveries in 
<a href="http://sourceforge.net/projects/tjws/forums" target="discuss">the Discussion forum</a>.</p>
<h5>Extra Bonus</h5>
<p>Version of 1.07 and later includes some useful web applications packaged as
.war files and deployed at first server run. To enjoy the applications just
follow a link on a start page. If you do not want to have these applications
deployed, just remove corresponding .war files from <i>webapps</i> directory
before first server run.</p>
    <h5>
        Help wanted</h5>
<p>I'm looking for developers to finish work on pending web.xml, fragment.xml, and common.xml instructions. Another plan is adding SOAP/RPC support for easy SOA. 
SSI servlet is also waiting to be developed. There are tons opportunities to develop Android web applications.</p>
<h5>Check also...</h5>
<p><a target="_blank" href="http://mediachest.sourceforge.net">MediaChest</a> Comprehensive tools to handle all media files as digital photos and&nbsp; music</p>
<p><a target="_blank" href="http://xbox.sourceforge.net">xBox</a> - Bean box supporting XML serialization
(do not confuse with proposed
later <b>java.beans.Encoder</b>)</p>
<p><a target="_blank" href="http://jaddressbook.sourceforge.net">jAddressBook</a> is an address
book with a float XML format of addresses and another profile information, web 2 
UI.</p>
<p><a target="_blank" href="http://sourceforge.net/projects/musicbarrel/?source=directory">Music Barrel</a> Conver any computer including Raspberry Pi to 
a music jukebox remote controllable from your phone or tablet.</p>
	<p><a target="_blank" href="http://webfolder.sourceforge.net/">Remote file management</a> - the tool every IT professional or advanced user must have, web interfaced file manager with many useful functions.</p>

<a name="contact"></a><h4>Contact</h4>
<p>Bugs, questions, and enhancement requests you can send to 
<a href="mailto:jAddressBook@gmail.com">Dmitriy
Rogatkin</a>.Happy web servicing!</p>
<p>
<center>&copy; 2015</center>
</body>
</html>
   